Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-033

Text File | 1995-12-31 | 78.1 KB | 2,234 lines | [TEXT/R*ch]

Received-Date: Thu, 9 Jun 1994 15:14:41 +0200
From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-033
To: [e-mail]
Date: Thu, 9 Jun 94 15:14:29 MET DST
X-Mailer: ELM [version 2.3 PL11]
Errors-To: [e-mail]
Reply-To: [e-mail]
X-Sequence: 36

C.S.M.P. Digest             Thu, 09 Jun 94       Volume 3 : Issue 33

Today's Topics:

        (Summary) Flicker-Free Grey Rectange Dragging (w-code)
        68K drivers, PPC completion routines: HOW?
        Audio CD Configuration
        Compression Manager help!
        Fastest way to draw a line?
        Finding application & document folders???
        How to make a window "float" over other apps?
        Installing Gestalts -- how to set up A5 world?
        Looking for C code to display color PICT files
        Palette updates??
        PenPat((ConstPatternParam)gray) - why illegal cast?
        SC++ and __vtbl?



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users.  To search back issues
with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use
http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html.


-------------------------------------------------------

>From [e-mail] (Stephen C. Gilardi)
Subject: (Summary) Flicker-Free Grey Rectange Dragging (w-code)
Date: Wed, 18 May 1994 23:07:25 GMT
Organization: SQ Software via The World Public Access UNIX, Brookline, MA

Based on replies here, especially the one from Dean Yu, I have accomplished
decent flicker-free dragging of a grey rectangle.  It still exhibits the
"cursor flicker in certain horizontal screen bands" problem, but to a much
smaller degree than the code I originally posted.  I've noticed since then
that Finder's selection rectangle, and the Drag Manager's grey rect dragging
also exhibit the same cursor flicker to roughly the same extent as the code
here.

I experimented with a VBL task (SlotVInstall).  It's complicated because
one must install the task and make sure it is removed even if the application
exits abnormally. This implies installing a patch on ExitToShell, etc.
Also, the quality of the cursor tracking isn't acceptable (to me).  I read
an article in develop that said that generally waiting for vbl isn't a good
idea.  The author said for example that QuickTime doesn't sync to VBL.

Enclosed below is the code which I find acceptable.  It's a TCL (2.0)
CPane::DoClick method.  Incorporate this into a "Nothing" TCL application
(arrange for a DragPane to be displayed in a window).  Click and drag to
see good dragging using Regions in action.  Option-Click and drag to see a
simpler FrameRect-based algorithm.  The code is set up to use the simpler
method if it can't get memory go allocate a region (probably overkill).

Thank you all very much for your help!

--Steve

Stephen C. Gilardi
SQ Software
[e-mail]

/* start of code */

extern RgnHandle gUtilRgn;

void    CDragPane::DoClick(
    Point       hitPt,
    short       modifierKeys,
    long        when)
{
    Rect                dragRect;
    Boolean             tryRegions;
    RgnHandle           dragRgn;
    Point               oldPt;
    Boolean             savedAlloc;

    tryRegions = (modifierKeys & optionKey) ? false : true;

    PenNormal();
    PenPat(&QDGLOBALS(gray));
    PenMode(notPatXor);

    SetRect(&dragRect, 0, 0, 100, 100);

    OffsetRect(&dragRect, hitPt.h, hitPt.v);

    oldPt = hitPt;

    if (tryRegions) {
        savedAlloc = SetAllocation(kAllocCanFail);
        dragRgn = NewRgn();
        SetAllocation(savedAlloc);
    }
    else
        dragRgn = NULL;

    if (dragRgn) {
        RectRgn(dragRgn, &dragRect);
        CopyRgn(dragRgn, gUtilRgn);
        InsetRgn(gUtilRgn, 1, 1);
        DiffRgn(dragRgn, gUtilRgn, dragRgn);
        PaintRgn(dragRgn);
    }
    else
        FrameRect(&dragRect);

    while (WaitMouseUp()) {

        GetMouse(&hitPt);

        if (oldPt.h != hitPt.h || oldPt.v != hitPt.v) {

            if (dragRgn) {
                CopyRgn(dragRgn, gUtilRgn);
                OffsetRgn(gUtilRgn, hitPt.h - oldPt.h, hitPt.v - oldPt.v);
                XorRgn(dragRgn, gUtilRgn, dragRgn);
                PaintRgn(dragRgn);
                CopyRgn(gUtilRgn, dragRgn);
            }
            else {
                FrameRect(&dragRect);
                OffsetRect(&dragRect, hitPt.h - oldPt.h, hitPt.v - oldPt.v);
                FrameRect(&dragRect);
            }

            oldPt = hitPt;
        }

    }

    if (dragRgn) {
        PaintRgn(dragRgn);
        DisposeRgn(dragRgn);
        SetEmptyRgn(gUtilRgn);
    }
    else
        FrameRect(&dragRect);

    PenNormal();
}

/* end of code */

+++++++++++++++++++++++++++

>From [e-mail] (John Cooper)
Date: Fri, 20 May 1994 15:13:16 GMT
Organization: Vivid Technologies Inc.

I am reposting this post from last year from John Werner (where did he go,
BTW?) that covers this very issue. I got very good results from using his
C++ class.

   Note that in my application, I create the VBL task object in the init
routine of my MouseDragTask object. It is then removed when the MouseDragTask
object completes its task (when the mouse button is released).

- --------------------------------------------------------------------------
In article <[e-mail]>, [e-mail] (John
Cooper) wrote:

> I am developing an application that allows the user to drag outlines of
> objects around the screen and "drop" them onto other objects in my main
> app window. The problem I am encountering is an unsightly phase-in/phase-out
> effect whenever the object outline is moved around the upper half of the

What's probably going on is that your object gets drawn after the electron
beam has passed that part of the screen, then gets erased before the beam
passes again.  This can make the object disappear in certain places.

The way to fix this is to synchronize your drawing to the VBL interrupts on
the screen in question.  Your drawing loop will look something like this:

    Find the new mouse position
    Calculate the new object position and outline.
    Wait for the VBL interrupt
    Erase the old outline
    Draw the new one

The erase/draw steps need to be as fast as possible, so you can erase and
redraw the object before the monitor starts being repainted by the electron
beam.  That's why the calculations should get done before waiting for the
VBL.

The only hard part is waiting for the VBL interrupt.  The usual way of
doing this is to install a VBL task (using SlotVInstall or VInstall) that
increments a global counter somewhere.  When you want to wait for an
interrupt, your code sits in a tight loop waiting for the counter to
change.

I have some code that does this for TCL apps.  It's on ftp.brown.edu in (I
think) /pub/tcl/classes/CVblSync.something.  It will probably give you the
general idea of what to do even for non-TCL programs.

--
John Werner                      [e-mail]
UC Berkeley School of Education  510-596-5868 work, 655-6188 home



---------------------------

>From [e-mail] (Andrew Francke)
Subject: 68K drivers, PPC completion routines: HOW?
Date: Thu, 19 May 1994 19:09:16 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)

Scenario: You're using an old 68k driver (as in, 'DRVR') that somebody
else provides (as in, you don't have source ripe for porting). The
driver has completion routines for reads and writes that assume
they're calling 68k code, stuffing something interesting in A0, etc.

Picture:
+-----------+                         +----------------+
+   680x0   +                         |  PPC Code Frag |
+  Driver   + ------- callback ------\|   using driver |
+           + -----w/A0 parameter----/|                |
+-----------+                         +----------------+


Question: Is there a way to prototype a function such that it may be
compiled PPC native yet receive the parameter that vanilla 68k code
would see in A0? Had I read the "converting to universal headers"
article in d_e_v_e_l_o_p would I have known the answer? Is the answer
contained deep within the bowels of NIM:PowerPC System Software?

+++++++++++++++++++++++++++

>From [e-mail] (Zalman Stern)
Date: Thu, 19 May 1994 22:14:20 GMT
Organization: Adobe Systems Incorporated

Andrew Francke writes
> Question: Is there a way to prototype a function such that it may be
> compiled PPC native yet receive the parameter that vanilla 68k code
> would see in A0? Had I read the "converting to universal headers"
> article in d_e_v_e_l_o_p would I have known the answer? Is the answer
> contained deep within the bowels of NIM:PowerPC System Software?

Handling the calling convention aspect is pretty straight forward with Mixed
Mode. If you look in the Universal Headers version of Files.h you'll see the
following:

    uppIOCompletionProcInfo     =
kRegisterBased|REGISTER_ROUTINE_PARAMETER(1,kRegisterA0,kFourByteCode)

That's the procinfo for the routine you are interested in. If you stitch
your PowerPC code into a routine descriptor with that procinfo and hand it
to whatever wants a 68K routine you'll be in business. The prototype for the
PowerPC routine is something like "void CompletionProc(void *A0Arg);". (This
all assumes there aren't any other oddities other than the register based
calling convention.) And yes, reading the Power Macintosh IM docs will help.
--
Zalman Stern           [e-mail]            [phone]
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
   Never let a "final candidate" subscript get above the age of consent.

---------------------------

>From [e-mail] (Kamprath)
Subject: Audio CD Configuration
Date: 16 May 1994 21:04:01 -0400
Organization: America Online, Inc. (1-800-827-6364)

Do audio CDs have a data block which uniquely identifies a CD?  I ask because
even though I know that song titles and CD title is not saved on the CD (or am
I wrong), I want my program to be able to recognize a CD and be able to grab
user-entered data from a file which does contain the info.

Also, where in net-land (or Dev-CD land) can I find audio CD specs?  I've found
sample code for accessing and some tech notes on the CD ROM driver, but nothing
solely dealing with Audio CDs.

Thanks for any help,
Michael Kamprath
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Graham Cox)
Date: Thu, 19 May 1994 16:45:55 GMT
Organization: School of Information Systems, UEA, Norwich

In article <2r9561$[e-mail]>, [e-mail] (Kamprath)
wrote:

> Do audio CDs have a data block which uniquely identifies a CD?  I ask because
> even though I know that song titles and CD title is not saved on the CD (or am
> I wrong), I want my program to be able to recognize a CD and be able to grab
> user-entered data from a file which does contain the info.
>
> Also, where in net-land (or Dev-CD land) can I find audio CD specs?  I've found
> sample code for accessing and some tech notes on the CD ROM driver, but nothing
> solely dealing with Audio CDs.
>
> Thanks for any help,
> Michael Kamprath
> [e-mail]

Every CD has its serial number encoded on it, but NOT the title and track
titles. The serial number is usually (but not necessarily) the same as its
barcode number. I forget offhand exactly what calls you have to make to get
it, but it's documented in the usual places (Apple CD-ROM handbook, e.g.).
You can use this number to recover data from a database with title and
track names. This is what Apple's CD Audio Player does.


- ------------------------------------------------------------------------
Graham

#include <Std_Disclaimer.h>

-Everyone is entitled to their opinion, no matter how wrong they may be...
- ------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Simon Slavin)
Date: 20 May 94 17:43:30 GMT
Organization: Psychology Department, University of Manchester, England, UK

In article [e-mail], [e-mail] (Kamprath) writes:
>Do audio CDs have a data block which uniquely identifies a CD?  I ask because
>even though I know that song titles and CD title is not saved on the CD (or am
>I wrong), I want my program to be able to recognize a CD and be able to grab
>user-entered data from a file which does contain the info.
>
>Also, where in net-land (or Dev-CD land) can I find audio CD specs?  I've found
>sample code for accessing and some tech notes on the CD ROM driver, but nothing
>solely dealing with Audio CDs.

As someone who has spent a few happy hours writing code for CD-ROM drives,
especially the CS300, I'd better ante-up my 2c.

Part 1
- ----
There is *no* textual information standard for audio CDs.  There's no standard
for storing the artist's name, the album name, or the track names.
["But ..."  "Hold on, let me explain."]

Part 2
- ----
There *is* a standard for the unique numbering of a CD.  There's a space for
a unique (8-byte ?) number which could be assigned to each CD when the master
is finished - sort of like an ISBN.  With each CD having a unique number,
what happens is this:  You put your CD into the drive and your software
comes up with default names for the album and the tracks (like "Track 1", etc.).
You manually type in the names for the tracks and your software saves them
away in a file somewhere, keyed by the CD's unique number.
When you put the CD back in it reads the unique number, looks it up in the
file, and retrieves the track names you typed in before.

Now sit down comfortably and grab your favorite drink:  here's the kicker ...
No one uses the unique numbering system !  They all have the same code !
(There may be exceptions, but all the ones I tested have the same code.)
["But ..."  "Hold on, let me explain."]

Part 3
- ----
[At this point I was tearing my hair out ...]
What happens is that each driver which simulates this sort of thing makes
up its own unique code from various bytes it's read off of the disk.
There seems to be no standard for doing this.  The CD300 driver used in the
AV Macs takes the lead-out time of the CD (i.e. its length) which is
three BCD bytes long - minutes, seconds, frames, and the number of tracks
on the CD - another byte.  This gives it a 4-byte code which it hopes
is unique to that CD.
Doubtless, eventually someone will find two CDs which are both same length and
have the same number of tracks and complain that their software confuses them.

Thus endeth the lesson.  Feel free to go mad at your own pace.

The best source for Mac programming for Audio CDs and CD-ROM drives
which use the Mac driver is the Mac technical note DV-22, in all the normal
places you find Mac technical notes.

Simon.
- -
< "The natives showed considerable low cunning in using the brute force at >
< their disposal." - Christopher Anvil               [e-mail] >


+++++++++++++++++++++++++++

>From [e-mail] (Matt Mora)
Date: 23 May 1994 10:14:37 -0700
Organization: SRI International, Menlo Park, CA

In article <[e-mail]> [e-mail] (Graham Cox) writes:

>Every CD has its serial number encoded on it, but NOT the title and track
>titles. The serial number is usually (but not necessarily) the same as its
>barcode number. I forget offhand exactly what calls you have to make to get
>it, but it's documented in the usual places (Apple CD-ROM handbook, e.g.).
>You can use this number to recover data from a database with title and
>track names. This is what Apple's CD Audio Player does.

The old CD remote used the Numberoftracks and disc min,sec,frame as a unique
id. There is a call to get the ISBN or the CD ID number from the disk. I
don't know if the new apple player program uses the new calls or relies on the
old cd remote way of doing it. If you want your code to work on all Apple
drive is doesn't make sence to use two different Unique id's.

Below is code to show you how to get at the data.


Xavier


- --------

typedef struct {            // Address Struct
    Byte    track;
    Byte    min;
    Byte    sec;
    Byte    frame;
} Address;

typedef struct {
    Address    discID;
    short    resID;
} diskType;

typedef struct {
    short    version;
    short    count;
    diskType discList[];
} index;


index *MasterIndex;
diskType *discs;


void main (void)
{
  long  dirId;
  short   oe;
  short   resRef;
  FSSpec  theSpec;
  short   vRefNum;
  Handle  h;
  ResType rType = 'IndX';
  short   i;
  Address   tag;
  short   resNum;
  diskType dt;
  short x;
  short argc;
  char **argv;
  Str255  tempStr;
  InitMac();
  argc =  ccommand(&argv);

  oe  = FindFolder(-1,kPreferencesFolderType,false,&vRefNum,&dirId);
  oe = FSMakeFSSpec(vRefNum,dirId,"\pCD Remote Programs",&theSpec);
  resRef = FSpOpenResFile(&theSpec,fsRdWrPerm);
  if (resRef != -1) {
    h = GetResource(rType,128);
    if (h) {
      HLock(h);
      MasterIndex = (index *)*h;
      for (i=0 ;i<MasterIndex->count;i++) {
        dt = (MasterIndex->discList[i]);
        tag = dt.discID;
        resNum = MasterIndex->discList[i].resID;
        printf("Disk Id = %#lx\n",tag);
        printf("Disk Res ID = %d\n",resNum);


        x = 1;
          GetIndString(tempStr,resNum,x);
          p2cstr(tempStr);
          printf("Album Title: %s\n",tempStr);

        while (tempStr[0] != 0){
          x++;
          GetIndString(tempStr,resNum,x);
          p2cstr(tempStr);
          if (tempStr[0] != 0)
            printf("  Song %d : %s\n",x - 1,tempStr);

        }
        printf("------------------\n");
      }
      HUnlock(h);
      ReleaseResource(h);
    }
    CloseResFile(resRef);
  }

}
--
___________________________________________________________
Matthew Xavier Mora                       [e-mail]
SRI International                       [e-mail]
333 Ravenswood Ave                    Menlo Park, CA. 94025

+++++++++++++++++++++++++++

>From [e-mail] (Esa Ristil{)
Date: 24 May 1994 08:43:01 +0300
Organization: University of Tampere, Finland

According to Matt Mora:
>don't know if the new apple player program uses the new calls or relies on the
>old cd remote way of doing it. If you want your code to work on all Apple

The new player uses the same old method.

--
                       Esa Ristil{  *  [e-mail]
                             Homo homini lupus

---------------------------

>From [e-mail] (Mark Steele)
Subject: Compression Manager help!
Date: Fri, 20 May 1994 22:08:34 GMT
Organization: CIRES

Suppose that I have a file that I know is a JFIF. I want to get some
information on that image (dimensions, pixel depth, quality etc).
How would I go about collecting this information?
Is there a compression manager function that will do this for me?

Thanks for any help,
-Mark


--
Mark Steele                                     [e-mail]
                                          [e-mail]

+++++++++++++++++++++++++++

>From Mark Hanrek <[e-mail]>
Date: 21 May 1994 09:33:15 GMT
Organization: The Information Workshop

In article <mas-200594160451@192.149.148.115> Mark Steele,
[e-mail] writes:

> Suppose that I have a file that I know is a JFIF. I want to get some
> information on that image (dimensions, pixel depth, quality etc).
> How would I go about collecting this information?
> Is there a compression manager function that will do this for me?

There is example source code showing how to use the Image Compression
Manager to decode JFIF files.  You can find it either on the QuickTime
Developers Kit CD, or the regular Developer CD.  (not sure where I got
it)  You might also be able to find it at ftp.apple.com in the snippets
area.  It's called "JFIF->PICT".

In addition, use Archie or other means to locate "JPEG" on the internet,
and you will zero in on the Independent JPEG Group's source code.

In there, you will find a particular .c source code file that reads the
header information to discover what is known about a JPEG/JFIF file.

Hope this helps.

Mark Hanrek

+++++++++++++++++++++++++++

>From [e-mail] (Juergen Kehrer)
Date: 24 May 1994 06:13:45 GMT
Organization: Uni-Ulm / Verteilte Systeme

Hi,
here a is some code to decompress a JFIF file/resource/datastructure:


00000000000000000000000000000000000000000000000000000000000000000000000

PROCEDURE DrawMJPEGFrame (aWindow : GrafPtr; DataSize: Integer; Data: Ptr);
    VAR
        savedPort: GrafPtr;
        srcRect: Rect;
        descH: ImageDescriptionHandle;
        myErr: OSErr;
        theName: Str31;


    BEGIN
        GetPort(savedPort);
        SetPort(GrafPtr(aWindow));
        descH := ImageDescriptionHandle(NewHandle(sizeof(ImageDescription)));
        HLock(Handle(descH));
        WITH descH^^ DO BEGIN
            idSize := sizeof(ImageDescription);
            cType := 'jpeg';
            resvd2 := $0;
            dataRefIndex := 0;
            version := 1;
            revisionLevel := 1;
            vendor := LongInt('appl');
            temporalQuality := 0;
            spatialQuality := 0;
            width := 160;
            height := 120;
            hRes := Long2Fix(72);
            vRes := Long2Fix(72);
            dataSize := 0;
            frameCount := 1;
            theName := 'Photo - JPEG';
            BlockMove(@theName[0], @name[0], LongInt(theName[0]) + 1);
            depth := 24;
            clutID := -1;
        END;
        WITH aWindow^.portRect DO
            SetRect(srcRect, 0, 0, right - left, bottom - top);
        myErr := DecompressImage(Data, descH, aWindow^.portPixMap, srcRect,
              aWindow^.portRect, srcCopy, NIL);
        IF myErr <> noErr THEN BEGIN
            ErrorHandling('Error -- DecompressImage: ', myErr);
        END;
        DisposeHandle(Handle(descH));
        SetPort(savedPort);
    END;    { DrawMJPEGFrame }


00000000000000000000000000000000000000000000000000000000000000000000000

As far as I remember you only have to fill cType, depth, clutID (-1)
of the ImageDescriptionHandle. The decompressed frame is displayed in
aWindow in fullsize.

Best regards,
    J.Kehrer

===============================================================
Juergen Kehrer
University of Ulm/Germany
Dept of Distributed Systems
Internet: [e-mail]
===============================================================

---------------------------

>From [e-mail] (Paul Hoyer)
Subject: Fastest way to draw a line?
Date: 23 May 1994 14:44:59 +0300
Organization: University of Helsinki

I need a fast way to draw a line on the screen, an algorithm actually.
Because what I'm doing isn't actually drawing the line (I'm stepping
through each pixel and performing some calculations), I can't simply use
the toolbox's line functions.

I would suppose that the fastest way would be to somehow get the line
into the form: "2 pixels right, 3 up, then 2 right again etc...", but
how? I remember reading somewhere something about "Fourier"-algorithms,
or something. Would anybody happen to have such an algorithm to spare?

Thanks!

-P. Hoyer <[e-mail]>


+++++++++++++++++++++++++++

>From Jochen Meyer <[e-mail]>
Date: Tue, 24 May 94 20:20:01 +0200  (MES)
Organization: Meyer & Son


In article <2rq4vr$[e-mail]>, Paul Hoyer writes:


> I need a fast way to draw a line on the screen, an algorithm actually.
> Because what I'm doing isn't actually drawing the line (I'm stepping
> through each pixel and performing some calculations), I can't simply use
> the toolbox's line functions.
>
What you need is the "Bresenham" algorithm. It is *the* algorithm for line
drawing and is also being used in a lot of other ways. It is documented in
probably every computer graphics book and is fairly easy to understand and
implement.

Jochen
[e-mail]

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Wed, 25 May 1994 21:01:09 GMT
Organization: Apple Computer

In article <2rq4vr$[e-mail]> Paul Hoyer, [e-mail]
writes:
> I need a fast way to draw a line on the screen, an algorithm actually.
> Because what I'm doing isn't actually drawing the line (I'm stepping
> through each pixel and performing some calculations), I can't simply use
> the toolbox's line functions.

As previously stated, the Bresenham algorithm is what you want. The standard
graphics reference I give people is "Computer Graphics: Principles &
Practice" by Foley, Van Dam, Feiner and Hughes (Addison-Wesley). Any
bookstore with a half decent CS selection should have it. It's expensive but
has so much stuff in it that you'll find it worthwhile.

Another point: If you plan on drawing this way, don't just call SetCPoint on
every pixel or you'll find it's very slow. Make yourself a GWorld, find the
PixMap and pixels, and write directly into the pixel buffer. Then you can
call CopyBits to display your results.

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From [e-mail] (Rob Lewis)
Date: Thu, 26 May 1994 14:23:34 GMT
Organization: New England Medical Center



Bresenham's algorithm for scan converting a line is the one you want.
He not only invented the algorithm, but proved that it was the most
efficient possible.  I don't have my graphics text with me, so I can't
post it now, but you can find it in many graphics texts which you can
find in a library.

- -

Rob Lewis                          [e-mail]
New England Medical Center
Neuroimaging Research Laboratory   --->  Audio ergo sum  <---

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Fri, 27 May 1994 19:10:42 GMT
Organization: Apple Computer

Rob Lewis, [e-mail] writes:
> Bresenham's algorithm for scan converting a line is the one you want.
> He not only invented the algorithm, but proved that it was the most
> efficient possible.

...except that in recent years other people have optimized his algorithm to
increase its speed by a factor of four. This isn't entirely fair; it
increases the speed of calculating which pixels to set by a factor of four.
In real graphics systems, actually plotting the pixel also takes some time,
so the improvement isn't as great.

For more info, jaunt to comp.graphics.algorithms and wait for the
infrequently-posted FAQ.

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From [e-mail] (David Wareing)
Date: 31 May 94 02:25:32 GMT
Organization: Apanix Public Access Unix, [phone] (5 lines)

Jens Alfke <[e-mail]> writes:

>Rob Lewis, [e-mail] writes:
>> Bresenham's algorithm for scan converting a line is the one you want.
>> He not only invented the algorithm, but proved that it was the most
>> efficient possible.

>...except that in recent years other people have optimized his algorithm to
>increase its speed by a factor of four. This isn't entirely fair; it
>increases the speed of calculating which pixels to set by a factor of four.
>In real graphics systems, actually plotting the pixel also takes some time,
>so the improvement isn't as great.

I copied the following post the last time this subject raised its head.
Thanks to Richard Johnson for posting it. As a special bonus, you get a
circle drawing algo thrown in free. No steak knives though. I have not
personally used or tested the code, so please direct all queries or
queeries to [e-mail]. You will have to roll
your own draw routine though.

BTW, the drawing implementation is at least as important as the code
itself. As Jens Alfke pointed out, create a GWorld, write directly to the
pixmap (see the csmp FAQ) and then copy to the screen from there. Don't
bother using SetCPixel or LineTo or anything like that - it would defeat
the purpose of actually using a fast algo.

===========================================================================


From: [e-mail] (Richard Johnson)
Date: Wed, 12 Jan 94 20:19:06 PST
Organization: Eagle's Nest BBS Fidonet 1:102/834.0 1-818-989-7845

Here's the bresnham line drawing code, and a circle drawing code. I hope
the
person who wanted the line drawing code a while back is still around. The
beauty of these algorithms is that they don't use division or floating
point
numbers, both of which use a lot of processing time, but they still produce
accurate results! Cool.

void DrawLine( short x1, short y1, short x2, short y2 )
{
     short xi,yi,dx,dy;

     if( x1 > x2 ) xi = -1; else xi = 1;
     if( y1 > y2 ) yi = -1; else yi = 1;
     dx = iabs(x2-x1);
     dy = iabs(y2-y1);
     WritePixel( win->RPort, x1,y1 );
     if( dy > dx )
     {
          j = dy;
          i = dy >> 1;
          do
          {
               y1 += yi;
               if( (i += dx) > dy ) { i -= dy; x1 += xi; }
               WritePixel( win->RPort, x1,y1 );
          } while( --j );
     }
     else
     {
          j = dx;
          i = dx >> 1;
          do
          {
               x1 += xi;
               if( (i += dy) > dx ) { i -= dx; y1 += yi; }
               WritePixel( win->RPort, x1,y1 );
          } while( --j );
     }
}

void Circle( short cx, short cy, short radius )
{
     short x, y, d;

     x = 0;
     y = radius;
     d = 3 - 2 * radius;
     do
     {
          WritePixel( win->RPort, cx + x, cy + y );
          WritePixel( win->RPort, cx + y, cy + x );
          WritePixel( win->RPort, cx + y, cy - x );
          WritePixel( win->RPort, cx + x, cy - y );
          WritePixel( win->RPort, cx - x, cy - y );
          WritePixel( win->RPort, cx - y, cy - x );
          WritePixel( win->RPort, cx - y, cy + x );
          WritePixel( win->RPort, cx - x, cy + y );

          x++;

          if( d < 0 )
               d += 4*x+6;
          else
          {
               d += 4*(x-y)+10;
               y--;
          }

     } while( x <= y );
}

-- Via DLG Pro v1.0

- -----------------------------------------------------------------------
| Richard Johnson            [e-mail]      |
| fidonet 1:102/834.0:       [e-mail]   |
- -----------------------------------------------------------------------

=========================================================================

--
David Wareing
Adelaide, South Australia         [e-mail]
- ------------------------------------------------------------
Overflight Software - Macintosh Games & Multimedia Programming

---------------------------

>From [e-mail] (Dick Startz)
Subject: Finding application & document folders???
Date: Mon, 09 May 1994 08:51:24 +0800
Organization: University of Washington

Can someone tell me how to have my program identify both the folder
containing my application (so I can find help files, etc.) and the folder
containing the document the user double-clicked (for the open dialog,
etc.).

I know one of these is the current directory at launch time, but which one?
How do I nail down the other one?

(Some days me and Inside Mac have a communications problem.)

Thanks in advance.
-Dick Startz

--
Richard Startz                Internet::[e-mail]
Professor of Economics        voice::         206-543-8172
University of Washington      fax::           206-685-6419
Seattle, WA 98195 USA

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 14 May 1994 02:03:02 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <startz-090594085124@128.95.72.95>, [e-mail] (Dick
Startz) writes:

>Can someone tell me how to have my program identify both the folder
>containing my application (so I can find help files, etc.) and the folder
>containing the document the user double-clicked (for the open dialog,
>etc.).

If you're running under System 7, then use GetProcessInfo() on your application
(the current process) to get an FSSpec to your application.  The FSSpec will
contain the volume reference number of the volume your application is on and
the directory ID of the folder your application is in. As for the document
files, you'll get their location from the open application Apple Events you get
telling you what files to open.

Since you may be getting open application events that point to several
documents in completely different locations (remember, the System 7 Finder lets
you select files from different directories at the the same time and Finder
alias files can resolve to files on different volumes), you shouldn't make too
many assumptions about the standard location of document files.

- Jim Luther


+++++++++++++++++++++++++++

>From [e-mail] (gadget)
Date: 16 May 1994 00:04:37 GMT
Organization: Never Never Land

>>Can someone tell me how to have my program identify both the folder
>>containing my application (so I can find help files, etc.) and the folder
>>containing the document the user double-clicked (for the open dialog,
>>etc.).
>
>If you're running under System 7, then use GetProcessInfo() on your application
>(the current process) to get an FSSpec to your application.  The FSSpec will
>contain the volume reference number of the volume your application is on and
>the directory ID of the folder your application is in. As for the document
>files, you'll get their location from the open application Apple Events you get
>telling you what files to open.
>
>Since you may be getting open application events that point to several
>documents in completely different locations (remember, the System 7 Finder lets
>you select files from different directories at the the same time and Finder
>alias files can resolve to files on different volumes), you shouldn't make too
>many assumptions about the standard location of document files.

(why do I have to have more lines of text than included information? nice
news reader here... *agit*)

Is there source code for any of this available anywhere?  Cause I'd like
exacctly the same thing.  To open data files in my folder, and accept
the apple events.  I'm sure this has been optomised many times over by
lots of people, and I really don't need to do it again do I?

Tim









+++++++++++++++++++++++++++

>From [e-mail] (Dick Startz)
Date: Mon, 16 May 1994 08:36:41 +0800
Organization: University of Washington

In article <2r1pim$[e-mail]>, [e-mail] (Jump Long)
wrote:

> In article <startz-090594085124@128.95.72.95>, [e-mail] (Dick
> Startz) writes:
>
> >Can someone tell me how to have my program identify both the folder
> >containing my application (so I can find help files, etc.) and the folder
> >containing the document the user double-clicked (for the open dialog,
> >etc.).
>
> If you're running under System 7, then use GetProcessInfo() on your application
> (the current process) to get an FSSpec to your application.  The FSSpec will
> contain the volume reference number of the volume your application is on and
> the directory ID of the folder your application is in. As for the document
> files, you'll get their location from the open application Apple Events you get
> telling you what files to open.
>
> Since you may be getting open application events that point to several
> documents in completely different locations (remember, the System 7 Finder lets
> you select files from different directories at the the same time and Finder
> alias files can resolve to files on different volumes), you shouldn't make too
> many assumptions about the standard location of document files.
>
> - Jim Luther

Thanks, that helps!  Anyone want to chime in with System 6 advice???

--
Richard Startz                Internet::[e-mail]
Professor of Economics        voice::         206-543-8172
University of Washington      fax::           206-685-6419
Seattle, WA 98195 USA

+++++++++++++++++++++++++++

>From [e-mail] (Stefan Arentz)
Date: Tue, 17 May 1994 01:00:38 GMT
Organization: Lunatech Software Development

In article <startz-160594083641@128.95.72.95>
[e-mail] (Dick Startz) writes:

[Very useful advice from a FileSystem Guru deleted]

> Thanks, that helps!  Anyone want to chime in with System 6 advice???

How about:

OSErr RefNumToFSSpec(short theRefNum, FSSpec *theSpec) {

    FCBPBRec        paramBlock;
    OSErr            theError;
    Str255            theName;

    paramBlock.ioCompletion    = nil;
    paramBlock.ioNamePtr    = theName;
    paramBlock.ioVRefNum    = 0;
    paramBlock.ioRefNum        = theRefNum;
    paramBlock.ioFCBIndx    = 0;

    theError = PBGetFCBInfo(¶mBlock, false);

    if (theError == noErr) {
        theSpec->vRefNum = paramBlock.ioFCBVRefNum;
        theSpec->parID = paramBlock.ioFCBParID;
        CopyPString(theName, theSpec->name);
    }

    return(theError);

}

theError = RefNumToFSSpec(CurResFile(), &applicationFileSpec);

If you use System 6, and don't want the FSSpec, this code is simple to
modify...

- ----------------------------------------------------------------------

Stefan Arentz        --       [e-mail]       --        Lunatech

+++++++++++++++++++++++++++

>From [e-mail] (Dick Startz)
Date: Tue, 17 May 1994 08:24:42 +0800
Organization: University of Washington

In article <[e-mail]>, [e-mail] (Stefan Arentz)
wrote:

> How about:
>
> OSErr RefNumToFSSpec(short theRefNum, FSSpec *theSpec) {
>
>     FCBPBRec        paramBlock;
>     OSErr            theError;
>     Str255            theName;
>
>     paramBlock.ioCompletion    = nil;
>     paramBlock.ioNamePtr    = theName;
>     paramBlock.ioVRefNum    = 0;
>     paramBlock.ioRefNum        = theRefNum;
>     paramBlock.ioFCBIndx    = 0;
>
>     theError = PBGetFCBInfo(¶mBlock, false);
>
>     if (theError == noErr) {
>         theSpec->vRefNum = paramBlock.ioFCBVRefNum;
>         theSpec->parID = paramBlock.ioFCBParID;
>         CopyPString(theName, theSpec->name);
>     }
>
>     return(theError);
>
> }
>
> theError = RefNumToFSSpec(CurResFile(), &applicationFileSpec);
>
> If you use System 6, and don't want the FSSpec, this code is simple to
> modify...
>
> ------------------------------------------------------------------------
>
> Stefan Arentz        --       [e-mail]       --        Lunatech

Many thanks, that's just what I need!
To clarify my understanding, is it correct that CurResFile() gives you the
application resource file (assuming you call before you change the resource
file, of course) and that I can pick up the folder of the document the user
double-clicked on by GetVol() and the code above setting ioVRefNum? (Run-on
sentence apologies...)
-Dick Startz


--
Richard Startz                Internet::[e-mail]
Professor of Economics        voice::         206-543-8172
University of Washington      fax::           206-685-6419
Seattle, WA 98195 USA

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 21 May 1994 02:37:02 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <startz-160594083641@128.95.72.95>,
[e-mail] (Dick Startz) writes:

(in response to my last posting)

>Thanks, that helps!  Anyone want to chime in with System 6 advice???

System 6, what's that? :-)

Under System 6, you can use GetAppleParms (see IM II-58) to get the
reference number of your application. Then, use PBGetFCBInfo (or the
GetFileLocation function which calls PBGetFCBInfo) in MoreFiles) to
get the volume reference number and parent directory ID of your
application.

After your application is launched under System 6, you can use
CountAppFiles and GetAppFiles (also in IM II starting on page II-57)
to find out what files to open or print.  Since GetAppFiles returns
only a vRefNum and a file name in the AppFile record (there isn't a
directory ID field in the record), that means the value in the
vRefNum field is a working directory number. So, you'll need to pass
the vRefNum field in the AppFile record to GetWDInfo to get the real
volume reference number and parent directory ID of the file the
AppFile record refers to.

That's it.

- Jim Luther (back from a week at the WWDC)


---------------------------

>From Thomas Reed <[e-mail]>
Subject: How to make a window "float" over other apps?
Date: 19 May 1994 14:36:19 GMT
Organization: Washington University

I've got an application that displays a small timer window.  I'd like to
add an option that would allow the user to have this timer window "float"
above all other windows, so that the window is visible at all times.
Does anyone know how I might be able to do this, and what the possible
effects of doing this are?  Is it the kind of thing that might break?
Will it cause a lot of slowdown?

Thanks in advance!

-Thomas
=====================================================
Thomas Reed                    Washington University
[e-mail]          Medical School
(also:  [e-mail])
- ---------------------------------------------------
Clothes make the man.  Naked people have little or no
influence on society.  -- Mark Twain
=====================================================

+++++++++++++++++++++++++++

>From Matt Slot <[e-mail]>
Date: 20 May 1994 04:32:05 GMT
Organization: University of Michigan

Thomas Reed, [e-mail] writes:
 > I've got an application that displays a small timer window.  I'd like to
 > add an option that would allow the user to have this timer window "float"
 > above all other windows, so that the window is visible at all times.
 > Does anyone know how I might be able to do this, and what the possible
 > effects of doing this are?  Is it the kind of thing that might break?
 > Will it cause a lot of slowdown?

I have written a small background app which demonstrates how to use
the new Text Services floating windows. There is an app I posted to
Sumex called MemWin which shows the final product. If you like the looks
of the program, drop me a line and I will mail the source to you. (I
may send a copy to alt.sources.mac, but I want to fix up something
tonite).

The information I found was in Inside Macintosh: Text, but that was not
sufficient to explain the intricacies. I ended up adding a jGNEFilter to
get clicks and updates (need to trap manually). The window *does* float
above all others, but it requires System 7.1 or later to get the Text
Services Manager support -- if you have that, you are using all supported
system software hooks. There is no apparent slowdown, and it works for
all systems I have tested.

Matt Slot
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Troy Gaul)
Date: 22 May 1994 04:43:51 GMT
Organization: Infinity Systems

In article <2rheg6$[e-mail]>, Matt Slot
<[e-mail]> wrote:

> Thomas Reed, [e-mail] writes:
>  > I've got an application that displays a small timer window.  I'd like to
>  > add an option that would allow the user to have this timer window "float"
>  > above all other windows, so that the window is visible at all times.
>  > Does anyone know how I might be able to do this, and what the possible
>  > effects of doing this are?  Is it the kind of thing that might break?
>  > Will it cause a lot of slowdown?
>
> I have written a small background app which demonstrates how to use
> the new Text Services floating windows. There is an app I posted to
> Sumex called MemWin which shows the final product. If you like the looks
> of the program, drop me a line and I will mail the source to you. (I
> may send a copy to alt.sources.mac, but I want to fix up something
> tonite).
>
> The information I found was in Inside Macintosh: Text, but that was not
> sufficient to explain the intricacies. I ended up adding a jGNEFilter to
> get clicks and updates (need to trap manually). The window *does* float
> above all others, but it requires System 7.1 or later to get the Text
> Services Manager support -- if you have that, you are using all supported
> system software hooks. There is no apparent slowdown, and it works for
> all systems I have tested.

I've had problems with this and other programs that use a Text Services
Manager window. The problem is that at times, clicks 'fall through' to the
application that is below the window.  This problem doesn't seem to happen
consistently, but it seems I can make it happen fairly quickly if I am
trying.

I remember a hack that Don Brown wrote at MacHack last year that also had
this problem.  He wrote an INIT called TSMHelper that tried to compensate
for these 'misses', but still there were problems.

Another problem with this kind of window is that it doesn't seem to have
control over the cursor, so the cursor will depend upon whatever window it
happens to be floating on top of.  I suppose this would be tough to do,
even through a jGNEFilter, since other applications would expect to have
control of the current cursor

Just my $.02.

_troy
//////// //////___Troy [e-mail]__ //
  //    //       Infinity Systems ; West Des Moines, Iowa              //
 //    //  //  "Insert witty quote here."                             //
//    //////________________________________________________________ //

+++++++++++++++++++++++++++

>From [e-mail] (Grobbins)
Date: 22 May 1994 12:59:11 -0700
Organization: Skunkworks

In article <[e-mail]>,
Troy Gaul <[e-mail]> wrote:
>I've had problems with this and other programs that use a Text Services
>Manager window. The problem is that at times, clicks 'fall through' to the
>application that is below the window.  This problem doesn't seem to happen
>consistently, but it seems I can make it happen fairly quickly if I am
>trying.

The best theory I've heard to explain this (I haven't been able to confirm
it) is that the process manager is looking down the event queue for mouse
clicks that would change the current process, and it steals those
events to make the major switch occur more quickly.  Since the clicks never
reach the head of the event queue, GNEFilters never see them.

Grobbins             [e-mail]

Usual disclaimers apply.

+++++++++++++++++++++++++++

>From [e-mail] (Robert S. Mah)
Date: Sun, 22 May 1994 22:32:09 -0500
Organization: One Step Beyond

[e-mail] (Grobbins) wrote:

> Troy Gaul <[e-mail]> wrote:
> >I've had problems with this and other programs that use a Text Services
> >Manager window. The problem is that at times, clicks 'fall through' to the
> >application that is below the window.  This problem doesn't seem to happen
>
> The best theory I've heard to explain this (I haven't been able to confirm
> it) is that the process manager is looking down the event queue for mouse
> clicks that would change the current process, and it steals those events
> to make the major switch occur more quickly.  Since the clicks never reach
> the head of the event queue, GNEFilters never see them.

I think you're right (or pretty close).  I had to patch PPostEvent (or was
it just _PostEvent?) to keep those clicks from reaching the system.  This
works consistantly and only lets clicks that _I_ want through to the
system.

Cheers,
Rob
___________________________________________________________________________
Robert S. Mah  -=-  One Step Beyond  -=-  212-947-6507  -=-  [e-mail]

---------------------------

>From Thomas Reed <[e-mail]>
Subject: Installing Gestalts -- how to set up A5 world?
Date: 16 May 1994 14:42:37 GMT
Organization: Washington University

I wanted to install some Gestalt selectors for a program I'm writing, but
there's just one small problem.  According to IM VI, I need to set up my
app's A5 world in the function that is called to return the result code.
I've done this kind of stuff in VBL tasks, Notification Manager tasks,
and Sound Manager callback routines, but in every one of those cases,
there's a way to send the function the value of your app's A5.  But,
there's no way to pass this info to the result code function.  So how do
I do it?

Thanks in advance for any help!

-Thomas
=====================================================
Thomas Reed                    Washington University
[e-mail]          Medical School
(also:  [e-mail])
- ---------------------------------------------------
Clothes make the man.  Naked people have little or no
influence on society.  -- Mark Twain
=====================================================

+++++++++++++++++++++++++++

>From [e-mail] (Rene G.A. Ros)
Date: Mon, 16 May 1994 17:57:18 GMT
Organization: VU Biology, Amsterdam, The Netherlands

[e-mail] (Thomas Reed) writes:
: I wanted to install some Gestalt selectors for a program I'm writing, but
: there's just one small problem.  According to IM VI, I need to set up my
: app's A5 world in the function that is called to return the result code.
: I've done this kind of stuff in VBL tasks, Notification Manager tasks,
: and Sound Manager callback routines, but in every one of those cases,
: there's a way to send the function the value of your app's A5.  But,
: there's no way to pass this info to the result code function.  So how do
: I do it?
:
You can use the GestaltValue code from Apple to install a long and don't
bother with your own GDEF function at all...
The GestaleValue Lib adds three functions: NewGestaltValue, ReplaceGestaltvalue,
and DeleteGestaltValue. These functions will be part of a future system
version and the library code already checks for this and will call the
GestaltValueDispatch trap when it is available.

See the Gestalt Selectors List for more info. Or download the GestaltValue
Lib from sumex (info-mac) mirrors. I think it is in the /dev directory.
And the Gestalt List is avalable as /dev/info/gestalt-selectors-24.hqx

Bye,
Rene

PS. I remember seeing your name with more postings about Gestalt. Isn't it
time to subscribe to the Gestalt Selectors List and receive updates as well?
Contact me (the editor of that list) for more info. Bye!

--

- ------------------------------------------------------------------------------
  Rene G.A. Ros                                      Amsterdam, The Nederlands
  [e-mail]         [e-mail]          [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Mon, 16 May 1994 19:46:37 GMT
Organization: cellular

Thomas Reed <[e-mail]> writes:

>I wanted to install some Gestalt selectors for a program I'm writing,
>but there's just one small problem. According to IM VI, I need to set
>up my app's A5 world in the function that is called to return the
>result code. I've done this kind of stuff in VBL tasks, Notification
>Manager tasks, and Sound Manager callback routines, but in every one of
>those cases, there's a way to send the function the value of your app's
>A5. But, there's no way to pass this info to the result code function.
>So how do I do it?

This is not your only problem. The Gestalt Manager is very picky about
where it thinks your Gestalt selector function ought to live. If it's
not in the System Heap, the Gestalt Manager won't let you install the
function. There's also the problem of what to do when your app quits.
The Gestalt Manager doesn't support a call to remove your selector
function.

I once solved all three of these problems with a 68K hack. Those are
passe now that PowerPC is here. Neverthless, on the off chance you feel
like messing with it, here's the poop:

In the System Heap, allocate a struct and inside it a union and a
state variable. The state variable has two possible values indicating
the state of the union (yes, pun intended -- sue me). If your app is
running, the union should contain the relevant value of A5 and some code
to set it up and call code which lives inside your app. If your app is
not running, the union should contain code which returns a suitable
error code. Make sure the offsets into the struct are the same for
the code in both the active and inactive state. You might do this by
using the value of A5 as the state variable -- 0 indicates the block is
inactive, and anything in the struct after that value is assumed to be
code.

When your app starts up, it should check to see if the block in the
System Heap has already been installed by querying Gestalt for the
address of the function which corresponds to your selector. If it's not
there, create it in the active state. If it's there, assume it's in the
inactive state and rewrite it so that it's in the active state. When
your app quits (and it's best to do this in a patch to ExitToShell,
although I don't think I bothered), rewrite the block so it's in the
inactive state. (For some added safety, don't ever assume it's in the
inactive state and warn the user with a confirmation dialog before
transforming it.)

When you're done, you've just committed a nasty self-modifying code
trick, so all relevant caveats apply.

KEY POINT: you're much better off with AppleEvents.

But sometimes performance demands such disgusting hacks as the one I
have described here. There is even an Apple-described (although probably
not Apple-sanctioned) library for achieving this end, although the
relevant reference eludes me presently. Probably 'd e v e l o p'.

If you would like to strike a balance between performance and elegance,
consider an auxilliary system extension which implements your Gestalt
selector on your app's behalf. This sacrifices some user convenience
and a little bit of memory *and* makes you work a little bit if you
still want the meat of your Gestalt selector function inside your app.
However, on the up-side, it might even port to PowerPC without too much
of a hassle.
--
 Pete Gontier, CTO, Integer Poet Software; [e-mail]

 C   credo: "Trust the programmer."
 C++ credo: "Put the muzzle of a shotgun in your mouth and
             give the programmer the trigger..."

+++++++++++++++++++++++++++

>From [e-mail] (Stefan Arentz)
Date: Tue, 17 May 1994 00:54:57 GMT
Organization: Lunatech Software Development

In article <[e-mail]>
Thomas Reed <[e-mail]> writes:

> I wanted to install some Gestalt selectors for a program I'm writing, but
> there's just one small problem.  According to IM VI, I need to set up my
> app's A5 world in the function that is called to return the result code.
> I've done this kind of stuff in VBL tasks, Notification Manager tasks,
> and Sound Manager callback routines, but in every one of those cases,
> there's a way to send the function the value of your app's A5.  But,
> there's no way to pass this info to the result code function.  So how do
> I do it?

Here's some that I used:

// RememberA5.h - Written by Stefan Arentz, May 1994

asm static void __GetA5Storage(void) {
        bsr.s   a             //
        dc.l    0             //  store A5 here
    a:  move.l  (sp)+,a0      //
}

asm static void RememberA5(void) {
        jsr    __GetA5Storage  //
        move.l a5,(a0)         //
}

asm static void SetUpA5(void) {
        move.l a5,-(sp)        //
        jsr    __GetA5Storage  //
        move.l (a0),a5         //
}

asm static void RestoreA5(void) {
        move.l (sp)+,a5        //
}

Now, to install the Gestalt selector you do the following:

#include "SetUpA5.h"

void foo(void) {

    // This stores the current value of A5 in __GetA5Storage.
    RememberA5();

    OSErr theError = NewGestalt(kMyGestaltSelector, MyGestaltProc);

}

pascal void MyGestaltProc(...) {

    // Remember the current A5 on the stack, and set A5
    // to the one we remembered before installing the selector.

    SetUpA5();

    // Do your work here...

    // ...

    // And restore A5.

    RestoreA5();

}

> Thanks in advance for any help!

You're welcome :-)

- ----------------------------------------------------------------------

Stefan Arentz        --       [e-mail]       --        Lunatech

+++++++++++++++++++++++++++

>From [e-mail] (Dale Semchishen)
Date: Tue, 17 May 94 10:47:39 -0700 (PDT)
Organization: MIND LINK! - British Columbia, Canada

In article <[e-mail]>, [e-mail] (Stefan Arentz)
writes:
>
>
>         ... [ stuff deleted ] ...
>
> Here's some that I used:
>
> // RememberA5.h - Written by Stefan Arentz, May 1994
>
> asm static void __GetA5Storage(void) {
>         bsr.s   a             //
>         dc.l    0             //  store A5 here
>     a:  move.l  (sp)+,a0      //
> }
>
>         ... [ stuff deleted ] ...
>


Isn't this self-modifying code?

When memory protection is available on a future version
of the Mac OS I believe that the code segment will be protected
such that only read access will be allowed.

--
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Bruce Hoult)
Date: Thu, 19 May 1994 23:24:44 +1200 (NZST)
Organization: (none)

[e-mail] (Dale Semchishen) writes:
> Isn't this self-modifying code?
>
> When memory protection is available on a future version
> of the Mac OS I believe that the code segment will be protected
> such that only read access will be allowed.

You mean like it is for PowerMac native programs when virtual memory
is turned on?

..course the posted code was 68K Asm, so the question is moot in that
case.


Also, that wasn't actually self-modifying code, since the memory location
in question is never exceuted as code, just used to store data, so it's
perfectly cache-safe.

-- Bruce

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Fri, 20 May 1994 22:36:48 GMT
Organization: cellular

[e-mail] (Dale Semchishen) writes:

>> asm static void __GetA5Storage(void) {
>>         bsr.s   a             //
>>         dc.l    0             //  store A5 here
>>     a:  move.l  (sp)+,a0      //
>> }

>Isn't this self-modifying code?

Uh, sort of. Strictly speaking, yes. However, it does not succumb to the
pitfalls associated with self-modifying code currently. Note that the
DC.L declaration is data and stays that way. If it were ever executed
code, you might run into cache problems.

>When memory protection is available on a future version of the Mac OS
>I believe that the code segment will be protected such that only read
>access will be allowed.

On the other hand, I doubt this memory protection will ever appear on a
68K-based Mac, so this code will not be present anyway. :-)
--
 Pete Gontier, CTO, Integer Poet Software; [e-mail]

 "Bedrock does support a form of drag and drop. Development dragged on
 for about two years, and then was dropped." -- Brian Clark

+++++++++++++++++++++++++++

>From [e-mail] (Matt Mora)
Date: 23 May 1994 10:19:34 -0700
Organization: SRI International, Menlo Park, CA

In article <[e-mail]> [e-mail] (Pete Gontier)
writes:

>>When memory protection is available on a future version of the Mac OS
>>I believe that the code segment will be protected such that only read
>>access will be allowed.

>On the other hand, I doubt this memory protection will ever appear on a
>68K-based Mac, so this code will not be present anyway. :-)

Not so fast, Pete. That's not what the said a the WWDC. :-)


Xavier

--
___________________________________________________________
Matthew Xavier Mora                       [e-mail]
SRI International                       [e-mail]
333 Ravenswood Ave                    Menlo Park, CA. 94025

---------------------------

>From [e-mail] (Russ Poldrack)
Subject: Looking for C code to display color PICT files
Date: 24 May 1994 15:36:28 GMT
Organization: UIUC Department of Psychology

I need to display color PICT files to the screen using THINK C.  I
can't find any code in the archives that will help me do this, and my
translation of the Pascal code from IM5 won't work.  Any help would be
greatly appreciated.

Russ Poldrack
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Ken Long)
Date: Tue, 24 May 1994 22:05:18 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

: I can't find any code in the archives that will help me do this....

Then you are not looking in enough archives.

Check in the Apple ftp's dts directory - there are a lot of projects
there that will read a pict.  I'll bet DTS/Draw would open  'PICT' file.

Also, look in the develop code files.  (Get an all-file list of any
directories you look into.)  "Is this art?" may be one to check.

Look on the Mac FTP List.  There are ftp's listed, with archives,
containing all sorts of C source code projects.  Chuck Hoffman's GTE ftp
directory has Chassis v6, which will open a 'PICT' as I recall.  That
file is on other ftp's as well.

Scour any and ALL potential locations for downloadable Think C example
source.  Get another hard drive to handle it.  Example source is a
successful programmer's way of saying "Here's how you do...!"  The more
you have, the more answers you have.

-Ken-

+++++++++++++++++++++++++++

>From [e-mail] (Grobbins)
Date: 25 May 1994 11:05:31 -0700
Organization: Skunkworks

In article <2rt6ts$[e-mail]>,
Russ Poldrack <[e-mail]> wrote:
>I need to display color PICT files to the screen using THINK C.  I
>can't find any code in the archives that will help me do this

Here's a basic routine from the code for SimpleDrag (documented in
develop 16, and available on the develop Bookmark CD.)  It extracts the
picture from a pict file into a handle, which can then be used in a
call to DrawPicture.  It is not suitable for some large picture files;
an incremental routine (more like what's done in IM V) would be better
for the general case.

Grobbins            [e-mail]

Usual disclaimers apply.

____________

from SimpleDrag.c:

// SetWindowPictureFromFile reads the PICT file specified by pictSpec
// and replaces the window's picture with the new one by calling
// SetWindowPicture

OSErr SetWindowPictureFromFile(FSSpecPtr pictSpec, WindowPtr theWindow)
{
    OSErr        retCode;
    short        pictRefNum;
    long        fileLength;
    Size        pictSize;
    Handle        tempHandle;

    pictRefNum = 0;
    tempHandle = nil;

    // open the file and find its size
    retCode = FSpOpenDF(pictSpec, fsRdPerm, &pictRefNum);
    if (retCode != noErr) goto Bail;

    retCode = GetEOF(pictRefNum, &fileLength);
    if (retCode != noErr) goto Bail;

    // skip over 512-byte pict file header
    retCode = SetFPos(pictRefNum, fsFromMark, 512);
    if (retCode != noErr) goto Bail;

    pictSize = fileLength - 512;

    // allocate a buffer for the file's picture data,
    // in temp memory if it is available
    if (gHasRealTempHandlesFlag)
        tempHandle = TempNewHandle(pictSize, &retCode);
    else {
        tempHandle = NewHandle(pictSize);
        retCode = MemError();
    }
    if (tempHandle == nil) goto Bail;

    // read in the picture data
    HLock(tempHandle);              // paranoid
    retCode = FSRead(pictRefNum, &pictSize, *tempHandle);
    HUnlock(tempHandle);
    if (retCode != noErr) goto Bail;

    // replace the window's picture with the new data
    retCode = SetWindowPicture(theWindow, (PicHandle) tempHandle);

Bail:
    if (pictRefNum != 0) FSClose(pictRefNum);
    if (tempHandle != nil) DisposeHandle(tempHandle);

    return retCode;
}


---------------------------

>From [e-mail] (Yimmit)
Subject: Palette updates??
Date: Fri, 20 May 1994 18:42:24 GMT
Organization: Imladris Occupants Inc.

Hi all!

I have a quick question that one of you may be able to answer.  I am working
on a program that opens TIFF files and has a floating window on screen at all
times.  My problem is that the palette I set for the window doesn't change the
device CLUT when I display the window.  I'm guessing this is because the
floater still looks like the front window to the monitor driver (?)  How can I
force the palette to be used?  I have tried ActivatePalette sending the window
in, but it didn't work.  Does anyone have any ideas?  Thanks in advance!!
-->Tim Damon


+++++++++++++++++++++++++++

>From [e-mail] (TR0Y GT)
Date: 20 May 1994 23:54:06 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>,
[e-mail] (Yimmit) writes:

Make sure that the palette entries you get from the TIF file are
setup as pmTolerant + pmExplicit, with a tolorance value of 0.  I
think SetPalette and NSetPalette both allow you to adjust the palette
entries' usage in this way. After you do this, then
ActivatePalette(). Doing this will force good color arbitration in
your floating Window.

[e-mail]

+++++++++++++++++++++++++++

>From Mark Hanrek <[e-mail]>
Date: 21 May 1994 09:41:14 GMT
Organization: The Information Workshop

In article <[e-mail]> Yimmit,
[e-mail] writes:

> My problem is that the palette I set for the window doesn't change the
> device CLUT when I display the window.

Someone else reported troubles recently when working with floating
windows.

It may be possible to skip the whole issue and do what Forest Tanaka does
in his "ResetColors" example source code found on the Developer CD.

I have done it before with HyperCard and it works great.  What you do is
temporarily create a 1 pixel square window in the extreme upper left
corner of the screen, which is masked out because of the rounded corners
of the Mac's screens. ( look up there now :).

Show this micro-dot window, NSetPalette, ActivatePalette, and then
dispose (or close, I can never remember which) the window, and go back to
what you were doing.

Hope this helps.

Mark Hanrek

+++++++++++++++++++++++++++

>From Joe Francis <[e-mail]>
Date: 23 May 1994 22:17:58 GMT
Organization: Smooth Roo Software

It's really weird that right after I post about this very problem it
comes up again.  I guess everyone is doing the same thing at the same
time.

Tim Damon writes:
> working on a program that opens TIFF files and has a floating window
> on screen at all times.  My problem is that the palette I set for the
> window doesn't change the device CLUT when I display the window.  I'm
> guessing this is because the  floater still looks like the front
> window to the monitor driver (?)  How can I force the palette to be
> used?  I have tried ActivatePalette sending the window in, but it
> didn't work.


TR0Y GT, [e-mail] writes:
> Make sure that the palette entries you get from the TIFF file are
> setup as pmTolerant + pmExplicit, with a tolerance value of 0.  I
> think SetPalette and NSetPalette both allow you to adjust the palette
> entries' usage in this way. After you do this, then
> ActivatePalette(). Doing this will force good color arbitration in
> your floating Window.

He is probably already doing this.  If I understand him correctly,
its not that he is not using the Palette Manager, it's that the
Palette manager refuses to honor ActivatePalette() requests for
anything other than the frontmost visible window in the application
window list.  He wants the Palette associated with his TIFF window
(sounds like we are writing the same app, Tim), not his floating window.

Mark Hanrek, [e-mail] writes:
> What you do is
> temporarily create a 1 pixel square window in the extreme upper left
> corner of the screen, which is masked out because of the rounded corners
> of the Mac's screens. ( look up there now :).
> Show this micro-dot window, NSetPalette, ActivatePalette, and then
> dispose (or close, I can never remember which) the window, and go back to
> what you were doing.

This approach is similar to my first cut at this problem (my first cut
was simply to figure out what my frontmost image window was, and bump
that palette up to the frontmost floating window).  The problem with
approaches like this is that it doesn't work well with multi-monitor
setups.

I don't think what I finally settled on is perfect either, but it's
the best I can come up with so far.  The basic idea is: every time you
move, drag, or select a window, to briefly swap that window to the
front of the window list (by directly manipulating the window list),
call ActivatePalette(), and then call PaintOne() on the backmost
floating  window with a region that corresponds to the structure
region of the selected window.

This seems to work perfectly except you get a brief flicker in the window
frame of any floating window that is over top of your image window.
(Actually, the flicker is only noticeable if the frames of the floating
window and the image window intersect.)

I posted source for using this with Dean Yu's floating windows code
to alt.source.mac just a few days ago.  I will email it to anyone
who wants it.

If you find problems, or come up with a better way, please let me know.

Thanks,
Joe Francis
Dartmouth College Information Systems

- ------------------------------------------------------------------------
"bolo needs to be on many machines just like MS Word" - Tempest
- ------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Yimmit)
Date: Tue, 24 May 1994 03:49:02 GMT
Organization: Imladris Occupants Inc.

>TR0Y GT, [e-mail] writes:
>> Make sure that the palette entries you get from the TIFF file are
>> setup as pmTolerant + pmExplicit, with a tolerance value of 0.  I
>> think SetPalette and NSetPalette both allow you to adjust the palette
>> entries' usage in this way. After you do this, then
>> ActivatePalette(). Doing this will force good color arbitration in
>> your floating Window.
>
>He is probably already doing this.  If I understand him correctly,
>its not that he is not using the Palette Manager, it's that the
>Palette manager refuses to honor ActivatePalette() requests for
>anything other than the frontmost visible window in the application
>window list.  He wants the Palette associated with his TIFF window
>(sounds like we are writing the same app, Tim), not his floating window.

Yeah, I already performed this one, unfortunately, ActivatePalette() did not
seem to do anything!  I finally figured out that the window I was using did
not look like the front active window as far as the Mac was concerned.
Apparently, ActivatePalette() only works when the srcWindow is THE front window.
My final solution, which seems to work, is to bring the TIFF window all the way
to the front, activate it's palette, then bring the floating windows back in
front of the image window.  This probably isn't the most elegant way since the
palette switch takes a while, and you can see the windows shuffling around, but
it works.

Thanks for all the replies!
-->Tim Damon

---------------------------

>From [e-mail] (Paul DuBois)
Subject: PenPat((ConstPatternParam)gray) - why illegal cast?
Date: 13 May 1994 16:43:25 -0500
Organization: Castra Parvulorum

Under THINK C 7 with the universal headers, the following line
results in "illegal cast".

    PenPat ((ConstPatternParam) gray);

How come?  This is legal in THINK C 6 with THINK's header files.
--
Paul DuBois
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Fri, 13 May 1994 22:55:36 -0700
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>, [e-mail]
(Paul DuBois) wrote:

> Under THINK C 7 with the universal headers, the following line
> results in "illegal cast".
>
>     PenPat ((ConstPatternParam) gray);
>
> How come?  This is legal in THINK C 6 with THINK's header files.

Patterns are different in the Universal headers (and in recent
pre-Universal MPW headers) than they were in the Think C 6 headers.  [They
are structs, not arrays.]  gray is now referenced as qd.gray, a pointer to
gray is now &qd.gray, and I haven't looked at ConstPatternParam but I
suspect it is a pointer to a const pattern, which would indeed cause an
illegal cast.
--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Sigurdur Asgeirsson)
Date: 17 May 1994 12:59:30 GMT
Organization: University of Iceland

In <[e-mail]> [e-mail] (Paul DuBois) writes:

>Under THINK C 7 with the universal headers, the following line
>results in "illegal cast".

>    PenPat ((ConstPatternParam) gray);

>How come?  This is legal in THINK C 6 with THINK's header files.

  If you look at the headers you'll see that a pattern used to be a char
array, but is now a struct containing a char array. In C and C++,
whenever you use an array it automagically degenerates to a pointer to
the type in question (except when used with sizeof). Furthermore, the
only allowable casts in C are between pointer types and various
int/float types, but what you're trying to do in the above code fragment
(with the new headers) amounts to casting something (probably a char*)
to a struct - this is not allowed. What you can do however is:

   PenPat(*(ConstPatternParam*)&gray);

--
Sigurdur Asgeirsson    | "Well you know, C isn't that hard, void (*(*f[])())()
Kambasel 26            | for instance declares f as an array of unspecified
109 Reykjavik, Iceland | size, of pointers to functions that return pointers to
[e-mail]     | functions that return void... I think"

---------------------------

>From Jochen Meyer <[e-mail]>
Subject: SC++ and __vtbl?
Date: Thu, 19 May 94 21:02:20 +0200  (MES)
Organization: Meyer & Son


Hello folks

After having updated from Symantec C++/MPW 6.01 to 7.0 I keep on getting a
linker error:

> ### Link: Error: Undefined entry, name: (Error 28) "_vtbl__7gr_line"
>   Referenced from: __ct__7gr_lineFv in file: groby.o

not only for this class gr_line, but for a variety of classes, large and small,
easy and complicated. Other classes - also very similar ones to the failing ones
- seem to compile and link perfectly fine. I tried lots of compiler switches,
read forward and backward through the manuals, looked for help in the info-mac
and elsewhere, changed my code, but no chance.

The error appeared for one class with the 6.01 compiler already but I could do
without that class. Now I really can't work around this error. Also, I cannot
continue my work, as long as that problem is not solved (the program does not
link!!!)

So: If you already had a similar problem: PLEASE, PLEASE: HOW DID YOU GET IT TO
WORK??? If not, at least send me a sympathetic mail.

Desperately
Jochen

--

| Jochen Meyer         |  Internet: [e-mail]   |
| Heuberge 12b         |  phone: +49 - 4432 - 1609 (voice)  |
| D-27801 Neerstedt    |                                    |
|-----------------------------------------------------------|
| "Eat a live toad in the morning,                          |
|     and nothing worse can happen to you the day"          |

+++++++++++++++++++++++++++

>From [e-mail] (AFC JLloyd)
Date: 20 May 1994 03:31:04 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>, Jochen Meyer
<[e-mail]> writes:

> After having updated from Symantec C++/MPW 6.01 to 7.0 I keep on
getting a
> linker error:
>
> > ### Link: Error: Undefined entry, name: (Error 28)
"_vtbl__7gr_line"
> >   Referenced from: __ct__7gr_lineFv in file: groby.o

Errors of this sort happen in several C++ compilers (see a very
recent Andy Koenig article in the C++ Report, sorry I don't have the
reference handy).  The problem happens because of something like
this:

1) Each class must have a vtbl generated once and only once.
2) Many translation units see the class declaration, so the compiler
can't generate a vtbl simply from seeing a class declaration.
3) Class methods should be defined in one and only one translation
unit, so if some particular method is considered the "magic" method,
then the compiler can generate the vtbl in the translation unit that
defines the magic method.
4) The compiler chooses some adhoc rule for defining the magic
method, such as the first virtual function listed in the class
declaration.
5) Something subtle foils the adhoc rule.

The example Koenig gives is when a programmer simply neglects to
implement the "magic" method.  Since the method is never implemented,
the compiler is never triggered to generate the vtbl for the class.
This can be a subtle problem to diagnose, because it's possible that
the programmer hasn't yet written any code that uses the magic
method, so she doesn't get a linker error telling her that the method
is undefined, but she does get the undefined vtbl message.

Symantec C++ used to have a problem like this (which I'm pretty sure
has since been fixed) which happened when the first method declared
in the header was defined as an inline later in the .h file, like so:

class foo
{
   void function1(void);
};

inline void function1(void)
{
   ...
}

While the problem existed, there was a workaround to add the inline
keyword in the class declaration, or to simply move the function
definition into the class declaration:

class foo
{
   void function1(void) {...}
};

This workaround allowed the compiler to realized that it couldn't use
that method as the "magic" method.

To avoid this problem, I personally chose to use the following coding
style guidelines:

1) Any class that has any virtual function must have a virtual
destructor.
2) The virtual destructor is always the first method in the class
declaration.
3) Virtual destructors are never declared to be inline.

By using these rules, the only times I've had undefined vtbl errors
is when I declare the destructor but forget to implement it (or when
the class is a template class and I have forgotten to instantiate it
with a #pragma template).

Jim Lloyd
[e-mail]


---------------------------

End of C.S.M.P. Digest
**********************